Optical Transport Network (OTN) is defined in various ITU Specifications such as, for example, ITU G.709/Y.1331 (December 2009) “Interfaces for the Optical Transport Network (OTN),” the contents of which are herein incorporated by reference. OTN allows network operators to converge networks through seamless transport of the numerous types of legacy protocols while providing the flexibility required to support future client protocols. Standards for Optical Transport Networks (OTN) have been extended to support a flexible rate Optical channel Data Unit (ODU) called ODUflex (GFP) (Generic Framing Procedure) to support the transport of variable packet rates and ODUflex (CBR) (Constant Bit Rate) to support fixed bit rates, of varying size. ODUflex is not only flexible, but may be resized in a hitless manner, that is, their rate may be increased or decreased in fixed increments while carrying but without affecting service. Optical transport bandwidth used to connect geographically separated packet switching sites currently needs to be provisioned to accommodate the peak demand. This can be inefficient when peak demand far exceeds typical demand. The current state of the art for ODUflex resizing is to implement the standard ODUflex resizing algorithms defined in ITU Recommendation G.7044/Y.1347 (10/11) “Hitless Adjustment of ODUflex (GFP)” (HAO), the contents of which are herein incorporated by reference.
However, an existing ODUflex channel must be resized by utilizing bandwidth over the same Optical channel Transport Unit (OTU) layer links carrying the existing channel, that is, resizing cannot be performed by switching to new OTU links. The procedures for this process specified in G.7044, even with the link restrictions, are complex and require the implementation of special and complex hardware/firmware and software to support the resizing operation. For example, G.7044 requires adjacency state machines and an end-to-end state machine as well as specialized hardware capabilities—a great deal of cost and complexity. In addition, the resizing operation using the standard approach may take as long as approximately 2 seconds to effect a full resizing operation depending on the magnitude of the resize operation. For example, G.7044 has a bandwidth rate change of 512,000 kbit per second. Finally, the existing resizing operation is limited to connections carried on links that have sufficient bandwidth to support the actual resizing. If any single link along the end-to-end path does not have the requisite available bandwidth, the resizing operation fails.